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@ An event system is provided within an object-oriented environment. The event system informs users and 
system functions of events within the system. Events may be modeled as objects that are visible wuhin the 
global namespace. These objects include event source objects and event sink objects. Event source objects 
generate event reports and event sink objects are the objects that receive reports. Special objects may be 
incorporated in the system to direct event reports from an event source object to an event sink object. 
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Technical Field '^-'^ / 

The present invention relates generally to data processing systems and. nnore particularly, to an event 
system for reporting system management events in a data processing system. 

5 

Background of the Invention 

Many distnbuted operating systems have difficulty in monitonng events. In particular, these operating 
systems have difficulty determining where events occur and obtaining useful, information about the events. 
'0 Such systems do not provide a convenient architecture for raising and sending events. 

Summary of the Invention 

In accordance with an aspect of the present invention, a method is practiced in a data processing 
;5 system in which a global namespace of objects is provided and stored in the memory means. Event source 
objects are provided for generating event report objects in response to events at the event source objects. 
An event sink object is provided for receiving event report objects and a distributor object is also provided 
for distnbuting event report objects from the event source objects to the event sink objects. The event 
source objects, the event sink object, the distnbutor object and the event report objects are all visible m the 

20 global namespace. An event is tnggered at one of the event source objects and an event report is 
generated in response to the event. The event report is generated at the event source object where the 
event was triggered. The event report object is forwarded to the distributor object. The distnbutor object 
forwards the event report object to the event sink object to inform the event sink object of the triggered 
event. The distnbutor object may be provided with a filter that is examined to determine where the report 
object should be forwarded. 

In accordance with an additional aspect of the present invention, a plurality of event source objects are 
provided along with a plurality of event sink objects and a distnbutor object. The event sink objects are 
registered with the distributor object to be informed of events at the event source objects. Event report 
objects are generated at the event source objects in response to events. The event report objects are 

30 forwarded Eo the distributor object, and the distributor object determines which event sink object should 
receive the event report objects. Once this determination is made, the event report objects are forwarded \o 
the determined event sink objects. 

In accordance with a further aspect of the present invention, a method is practiced in a data processing 
system having a storage device. In this method an event source object is stored in the storage device. The 

35 event source abject then raises events and generates event reports that report the generated events. Event 
sink objects are also stored in the storage device. An event source holder object is stored in the storage 
device, The event source holder object maintains a register of registrations by event source objects that are 
registered to receive an event report upon occurrence of an event at the event source object. An event is 
triggered at the event source object, and event reports are sent to event sink objects that are registered 

-0 with the event source holder object. 

In accordance with a still further aspect of the present invention, a method is practiced wherein an event 
source object is stored in the storage device. The event source object is capable of raising a set of events. 
Type information is stored about the event source object in the storage device. The type information 
specifies the set of events that the event source object may raise. 

J5 In accordance with a further aspect of the present invention, a method is practiced wherein at least one 
event source object is provided in the memory means for generating an event report in response to an 
event at the event source object. In addition, a first distnbutor object and a second distnbutor object are 
provided in the memory nneans. The first distributor object serves to distribute the event report then 
generated by the event source object to the second distributor object. An event is tnggered at the event 

50 source object and the event report is generated at the event source object. The event report is forwarded to 
the first distributor object. Filtering information is provided from the second distnbutor object to the first 
distnbutor object. The filtering information specifies a type of event report that the second distnbutor object 
wishes to receive. Where the fiitenng information indicates that the second distributor object wishes to 
receive the event report, the event report is forwarded from the first distributor object to the second 

55 distributor object. 

In accordance with a further aspect of the present invention, a method is practiced wherein an event 
source object for generating an event report tn response to an event is provided along with an event sink 
object for receiving the event report. In this method, the event sink object is registered to receive the event 
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repon from the event source object. As part of the registration, an instance of a function in an interface to 
be called by the event report as received by the event sink object is specified. 

Brief Descnption of the Drawings 

Figure 1 is a block diagram of a data processing system thai is suitable for practicing a preferred 
embodiment of the present invention. 

Figure 2A is a block diagram illustrating an instance of the preferred embodiment m which a single 
event report is sent from a single event source to a single event sink. 
JO Figure 2B is a block diagram illustrating an instance of the preferred embodiment in which a single 
event report is sent from a single event source to multiple-event sinks. 

Figure 2C is a block diagram illustrating an instance of the preferred embodiment m which multioie 
event sources send multiple event reports to a single event sink. 

Figure 2D is a block diagram illustrating an instance of the preferred embodiment in which a single 
T5 event source sends multiple event reports to multiple event sinks. 

Figure 3 is a diagram of the run time data structures used for interfaces by the preferred embodiment 
to the present invention. 

Figure 4 is a diagram of objects that play a role in the preferred embodiment of the present invention to 
register an event smk object with an event source object to receive event reports. 
«?o Figure 5 is a flowchart illustrating the steps performed by the preferred embodiment to register an event 
sink object with an event source object to receive event reports. 

Figure 6 ts a flowchart illustrating steps performed by the preferred embodiment of the present 
invention in generating and processing event reports. 

Figure 7 is a block diagram of a preferred embodiment of the present invention when a aistnbutor 
25 object is employed. 

Figure 8 is a block diagram illustrating propagation of an event rePort from a first distributor object lo a 
second distributor object in accordance with a preferred embodiment of the present invention. 

Detailed Description of the Invention 

30 

A preferred embodiment of the present invention provides an event system architecture for genera-mg 
system management events. The architecture is designed to be easily used and to require minimal 
overhead. The system management events notify processes of certain states. 

Figure i shows an illustrative data processing system 10 for practicing a preferred embodiment or -he 

35 present invention. Those skilled in the art will appreciate that other types of data processing systems may 
be used for practicing the present invention. The data processing system 10 includes a central processing 
. unit (CPU) 12 that oversees activities of the system. The CPU 12 communicates with a memory 14. a 
keyboard 16. a video display 18. a pnnter 19 and a mouse 24. The memory 14 holds an object-oriented 
operating system 20 that includes an event system 22. Although the operating system 20 of the preferred 

JO embodiment is an object-oriented operating system, those skilled in the art will appreciate that the present 
invention is not limited to such an object-onented environment. The keyboard 16 and mouse 24 are 
conventional input devices, and the video display 18 and printer 19 are conventional output devices. 

The event system 22 is responsible for overseeing the generation and transmission of event reports that 
report the occurrence of particular events in the system 10. An "event." in this context, is an asyn- 

-5 chronously arising condition relative to a destination process that wishes to be informed of the event. The 
process in which the condition arises is the "event source." whereas the process to which the event is 
reported is the "event sink." An "event report" reports an event and is transmitted from the event source to 
the event sink (as will be descnbed in more detail below). The event source and event sink are objects that 
are visible in a distributed namespace of the system lO. The distributed namespace is a logical organization 

so of the "names of objects" (described in more detail below) that are stored in the system 10. 

The preferred embodiment of the present invention allows application programs run on the system 10 
(Figure 1) to generate and receive information about external events without possessing knowledge about 
the events or the sources of the events. It provides a means for an event sink 27 (Figure 2A) to register with 
an event source 23 to receive an event report 25. The event sink 27 may then invoke an event handler to 

55 respond to the occurrence of the event. The design of the preferred embodiment leverages the distributed 
namespace of the system to provide places for event sinks to register. The preferred embodiment also 
provides a means to send the event report from the event source to the event sink. 
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It should be noted that an event report 25 need not be generated from a single event source 23 for 
transmission to a single event sink 27 as shown in Figure 2A. In many instances, a single event report 25 
may be sent from a single event source 23 to multiple event sinks 27, 27' or 27". as shown m Figure 2B. 
Moreover, a single event sink 27 may receive different event reports 25 and 25' from different event 
5 sources 23 and 23'. respectively, as shown in Figure 2C. Still further, a single event source 23 may 
generate different event reports 25 and 25' (Figure 2D) that are destined to different event sinks 27 and 27'. 
respectively. In general, an event source may generate multiple or single event reports that are destined to 
one or many event sinks. 

In order to understand how the preferred embodiment of the present invention operates, it is necessary 
w to first understand certain programming concepts that are employed therein. One of the concepts employed 
by the preferred embodiment of the present invention is the notion of an "object." An "object" is an entity 
that may be a combination of two things: data that specifies an Interna! state of the object and functions that 
act upon the data. 

The preferred embodiment of the present invention is designed far use in the object-oriented operating 

/5 system 20 (Figure 1). The operating system 20 supports an underlying object model. As such, many 
components in the system are modeled as objects. For example, event sources 23 {Figure 2a) and event 
sinks 27 are modeled as objects. Event reports may be objects having properties. Other objects of interest 
will be descnbed in more detail below. All of these objects are visible in the distnbuted namespace and 
thus their properties are easily accessible. 

20 A closely related concept is the concept of an "interface." An "interface" is a group of semantically 
related functions that are organized into a named unit (the name being the identifier of the interface). 
Interfaces, by definition, have no instantiation (i.e.. a definition of an interface does not include code for 
implementing the functions that are identified in the interface); rather, interfaces specify a set of signatures 
for functions. "Instantiation" refers to the process of creating in-memory structures that represent an obiect 

25 so that operations can be invoked on the object. When an object "supports" an interface, the object 
provides code for the functions specified by the interface. Thus, the object that supports the interface is 
responsible for providing the code for implementing the functions of the interface. The code that is provided 
must comply with the signatures of the functions specified by the interface (i.e., the code must have the 
same parameters and functionality as are specified in the interface). Accordingly, an interface may be 

30 Viewed as a standard with which objects must. comply. 

Interfaces support extensiblity by allowing new interfaces to be developed in a fashion that does not 
affect existing applications. Interfaces are also consistent with the client server model that is adopted by the 
operating system 20. In particular, interfaces are used to provide services to a client object. A server object 
IS defined to support the interface, and the interface defines the functions that provide the services of the 

35 server object. For instance, the event source 23 (Figure 2a) may be viewed as a server object, and the 
event sink 27 may be viewed as a client object. 

The run time manifestation of an interface instance is a data structure that provides access to the 
functions defined for the interface. Interface instances are referenced by clients using pointers. As shown m 
Figure 3, an interface pointer 28 points to an entry in the object data 29 of the object that supports the 

40 instance of the interface. In particular, the interface pointer points to an entry in the object data 29 that 
holds a pointer to a virtual table (i.e.. a vtable, such as commonly used in C + + programming). The vtable 
31 holds a series of pointers to instances of functions 33 that are supported by the object. Pointers to the 
functions included in the interface are among those provided in the vtable 31. 

Each object in the distributed namespace 28. by definition, must support the lUnknown interface (i.e.. all 

45 objects support interfaces that inherit the lUnknown interface). The lUnknown interface is a standardized 
interface provided by the operating system that includes a function, Querylnterface(), for querying whether 
an object supports a particular interface. The QuerylnterfaceO function returns a pointer to an instance of an 
interface that is specified in the parameters of the function. In general, whenever a function is called that ts 
part of an instance of an interface, the QuerylnterfaceO function must first be called. 

50 An interface pointer, such as returned by the QuerylnterfaceO function, may serve as a connection 
between an object and a client. It is difficult, however, for external entities to discover interface pointers that 
an object has dispensed, and it is difficult for external entities to discover interface pointers to other object 
objects that an object holds. To overcome these difficulties, the operating system 20 provides software 
connectors. Software connectors are standardized interfaces for connecting objects together and for 

55 advertising the interfaces of an object that are accessible by events. In general, a connection between 
objects in the preferred embodiment of the present invention is realized by passing an interface pointer 
from one object directly to another object m order to establish a meaningful connection between the 
objects. Both objects must share at least one connecting interface. Software connectors are utilized m the 
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preferred embodiment of the present invention to establish connections between an event source and an 
event sink. Thts process will be describee below as "registration'*. 

Before discussing how an event sink registers with an event source to receive event reports, it is heipfui 
■0 consider how events are defined relative to the objects that may generate them. In general, an object 
5 specifies an event set of events that it is capable of generating. The event set is part of the oojeci's 
definition and ts described in type information provided for the object. The type information may be stored 
in a storage structure that is separate from the object. The type information specifies which events are 
provided in the objects of that set. Consider as an example as object that supports an event set known as 
the DtskEventSet. This event set is identified as follows: 

10 

{ 

DiskSpaceLow( D Is kS pace Event psEvcm); 
Diskf uU(Di5k5paceEveat psEveat); 
Di5kError( DbkErrorEveat psEvent) 

^ 
f 

20 

DiskSpaceEvent is a property set that may be defined as follows: 



propset DiskSpaceEvent : public DiskEveac 



25 



{ 



L\RGE_LNTEGER 
L\RGE INTEGER 



D t5kS pac£*A.vaibble ; 
TotalDtskSpace; 



propset DLikEveat ; public ISystenLEvem 



{ 



} 



UT-ONG 
WCHAR * 



-^0 



J5 
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propset ISystemEvcnt 

{ 

mandatory: 

SYSTIME 

UUTD 

ULONG 

UVTD 

LT.ONG 

ULONG 

} 



LTVolumcID; 
pwzVolumcNamc; 



timcEventCreaciotiTime; 

uuidGassid; 

sevScverity; 

uuidCategorylD; 

ulEventCode; 

uiHopCouni; 
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Before discussing the registration process m more detail, it is useful to first introduce the objects which 
play a role within this registration process. Figure 4 is a diagram illustrating an example situation wherem 
the objects that play a role in registration are used. Figure 4 illustrates an instance wherein a printer 46 
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25 



generates an event report that it is lannmed and forwards this event report to a sink pop-up object 44 that 
generates a pop-up message on the video display 18 (Figure 1) that is viewed by the user, As discussed 
above, an event source object 42 is an object which generates event reports. The event source object 42 
supports the IConnectionContainer interface which is a standardized interface having functions for storing a 
connector in a container object. An event source holder object 50 is an object that maintains a list of 
registered event sinks for an event source object. The event source holder object 50 is responsible for the 
muiti-casting of event reports to each registered event sink object. In the example of Figure 4. the event 
source holder object 50 includes a list of all event sinks that are registered to receive event reports from the 
pnnter 46. An event source interface holder 54 object is an object that is a connection object (i.e.. it holds 
an interface pointer to an event sink object) and holds the state associated with the connection to the event 
sink object. In Figure 4. the event source interface holder object 50 holds a single event sink registration 
(i.e., it holds one entry from the register of event sink objects). 

Figure 5 is a flowchart of the steps performed to obtain a registration of an event sink object so that it 
receives event reports from an event source. C++ code for implementing these steps in a separate 
connection too! is as follows: 



pconSLiix->Quen-fQtertace(IIDJSystem£vcatSiiik, &pesakSink); 
//Setup [he source side of the registratioa 

pSource- > Queryfaterface(IID^rCoanecuoiiCoQiaincr, &piccSource) 
piccSoarce- > VewCnnnectioot nD_rEvcntSet, &pconSource); 
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/ / Actually perform the coonectioQ. 

pcotiiource->Coanect( pesoicSiaic, IID_ISystem£veacSinJc COMNECTFI^ PERSIST) 



Initially, a pointer to the event sink object (i.e., "pSink" m Figure 4) is obtained (step 56 in Figure 5). 
Next, a pointer to the event source object is obtained (step 62 in Figure 5). Specifically, the QuerylnterfaceO 
function IS called in the second instruction m the above code segment to determine whether the event 
source object 42 (pointed to by "pSource" in Figure 4) supports the IConnectionContainer interface and 
stores the resulting pointer to the instance of IConnectionContainer interface in "piccSource'V A connector 
to the event source object (i.e., a pointer to an interface that facilitates a connection to the object) is then 
acquired (step 64 in Figure 5). The call to the NewConnection method provided within the IConnectionCon- 
tainer interface of the event source object is used to store the connector m "pconSource". 

The connect function is then called to create a connection (step 66 in Figure 5) . In the code segment 
given above, the connect function within the ISystemEventSink interface supported by the event sink object 
40 is called to connect the event sink object 40 to the event source object 42. 

An event report in the preferred embodiment of the present invention is largely represented as an array 
of vanants. A variant is a data structure that can hold any fundamental data type, including character data 
integer data and floating point data. Property sets that contain context information descnbing an event are 
loaded into the vanants. This array of variants is passed as an event report type. Each event report may be 
encapsulated into an event report object that is persistently stored and visible within the distributed 
namespace. One of the properties held within the variant array is a class I.D. The class I.D. may be utilized 
to manufacture an event report object. 

Figure 6 is a high level flow chart of the steps performed to pass an event report from an event source 
object to event sink objects. Initially the event report is created by the event source object (step 70) The 
event source holder filters the output of the event report using the register stored therein and sends the 
report to the registered event sinks (step 72). The event sink receives the event report and calls an event 
handler to respond to the event report (step 74). The event handler then executes (step 78). The event 
handler may generate activity in response to the event report or may simply ignore the event report. A wide 
variety of options as to how to respond to an event report are available to an event handler. 
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A system may also include special obiects. known as "distributor objects.'* A disinbutor object s an 

object v;hich e:<!SiS in {he global namespace to route event reports to event sinks. Figure 7 depicts a 

dtstribuior object 32 mat receives event reports from event sources 80. 80' and 80". The distnbutor object 

32 provides both event source and event sink functionalities. The distnbutor object 82 rouies me event 
5 reports received from me event sources 80. 80' and 80" to event sinks 34. 84' and 84". Distnbutor objects 

82 are useful m grouping event sources and sinks as sets. For example, a distnbutor may be used to 

represent all aamimstrators on a given domain. 

A distnbutor object may also be configured to propagate event reports to other disinbutor objects. 

Figure 3 shows an example of a situation m which a distributor object 88 receives an event report 92 from 
;o an event source 86 and propagates the event report to a second distributor object 90. The difference 

between this type of propagation and the propagation that occurs with normal registration is that filtenng 

information 94 stored on the second distributor object 90 is forwarded to the first distributor object' 88. This 

filtering information specifies which type of event report the distributor object 90 is interested in obtaining. 

The first distributor object 88 filters the incoming event reports 92 to determine whether the second 
■'5 distributor object 90 wishes to receive the event report. The filtering information 94 is stored on the second 

distnbutor object m such a way that it is available to any distributor object that is registered to propagate 

event reports to the second distributor ob)ect. 

The operating system 20 provides a number of dispatch interfaces. A dispatch interface, in this context. 

is as defined in the Microsoft Object Linking and Embedding (OLE) 2.0 protocol, established by Microsoft 
30 Corporation of Redmond. Washington. Dispatch interfaces allow access to methods, properties and ca-a 

members of objects whose interface is not known. Each dispatch interface has functions that allow a caller 

to retrieve and send property values. The event distnbutor objects have the ability to cail any dispatcnabie 

interface. Parameter information is stored with the registration information for the event sink object. 

Prcoerties are set on the software connector to the event sink in the event source such that each 
25 registration can have its own interface to be called. As an example, this capability allows a system event lo 

trigger the printing of a word processing document through the call to the unique interface associaiec //ifh 

the registration of an event sink. 

It should be appreciated that registrations may be maintained over a period of time. Registratior-s are 

not stnctly a one-time phenomena. The registration need not be deleted after a single event occurs. 
30 Maintaining the registration is helpful in performing functions such as logging. Logging involves recorrimg 

event reports in a file to create a log. The tog may be later viewed to provide a histoncal record of ac'ivir/ 

of a part of the system. 

A preferred embodiment of the present invention enhances the ability of system administranon 
functions to become aware of relevant events within the system. This capability stems, m large par*, from 
35 segregating the occurrence of an event from the response to the event. The preferred embodiment also 
facilitates segregation by event type so that the system administrator may be aware of the different types of 
events and respond accordingly. 

Since event reports are objects in the global namespace, both users and system components have 
access to the event reports. The event reports include important state information that may be used by 
-10 users and system components alike. The user has the ability to discover what events a program js capable 
of generating and can register to receive notice of any such events. 

While the present invention has been described with reference to a preferred embodiment mereof. 
those skilled in the art will appreciate that various changes in form and scope may be maae witnout 
departing from the present invention as defined in the appended claims. For instance, the present invention 
-15 need not be practiced in a single processor system like that shown m Figure 1: rather the present invention 
may also be practiced in a distributed system. 

Claims 

50 1. In a data processing system having memory means and processing means, a method comprising the 
steps of: 

storing a global namespace of objects in the memory means; 

providing event source objects for generating event reports in response to events at the event 
source objects, an event sink object for receiving event reports and a distributor object for oistnouttng 
55 event reports from the event source objects to the event sink object: 
triggering an event at one of the event source objects: 

generating an event report at the event source object where the event was triggered: 
forwarding the event report to the distributor object: and 

7 
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forwarding the event report fronn the distributor object to the event sink object to inform the event 
sink object of the tnggered event. 

2. The method as recited in claim l, further comprising the step of registering the event sink with the 
distributor object to receive the event report. 

3. The method as recited in claim 1. further comprising the step of providing at least one additional event 
sink object that is visible in the global namespace. 

4. The method as recited in claim 3. further comprising the step of registenng the additional event sink 
object with the distnbutor object to receive the event report. 

5. The method as recited m claim 1. further comprising the step of providing the distributor object with a 
filter that is examined to determine where the event report should be forwarded. 

6. The method of claim 1 wherein the event report is an object that is visible in the global namespace. 

7. In a distributed system having processors running an object-oriented operating system, a method 
comprising the steps of: 

providing a plurality of event source objects; 
providing a plurality of event sink objects; 
providing a distributor object: 

registering the event sink objects wtth the distnbutor object to be informed of events at the event 
source objects: 

generating event reports at the event source objects in response to events at the event source 
objects; 

forwarding the event reports to the distnbutor object: and 

determining which event sink objects should receive the event reports and forwarding the event 
reports to the determined event sink objects. 

8. The method of claim 7 wherein the event report is an object that is visible in the global namespace, 

9. In a data processing system having a storage device, a method comprising the steps of: 

stonng an, event source object in the storage device, said event source object generating events 
and event reports that report the events: 

storing event sink objects in the storage device; 

storing an event source holder object m the storage device, said event source holder object 
maintaining a register of registrations by event sink objects that are registered to receive an event 
report upon occurrence of an event at the event source object: 

triggering an event at the event source object; and 

sending event reports to event sink objects that are registered with the event source holder object. 

10. The method recited in claim 9. further comprising the step of registenng an event sink object with the 
event source holder to receive an event report after an event is tnggered at the event source. 

11. The method recited in claim 9 wherein the step of sending event reports further comprises the step of 
sending a data structure holding property information about the triggered event to event sink objects 
that are registered with the event source holder object. 

12. The method recited in claim 9. further comprising the step of storing each registration in an object m 
the storage device. 

13. In a data processing system having a storage device, a method compnsing the steps of- 

storing an event source object .n the storage device, said event source object being capable of 
raising a set of events: and 

stonng type information about the event source object in the storage device, said type information 
specifying the set of events that the event source object may raise. 
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14. In a data processing system having inemory means and processing means, a method comprising '.he 
steps of: 

providing at least one event source object m ihe memory means for generating an eveni repori tn 
response to an event at (he event source object: 
5 providing a first distnbutor object and a second distributor object in the memory means, said first 

distributor object serving to distribute ihe event report when generated by the event source object to 
the second distributor object: 

triggering ihe event at the event source object: 

generating an event report at the event source object: 
;o forwarding the event report to the first distributor object: 

providing filtering information from the second distributor object to the first distributor object, satd 
filtering information specifying a type of event report that the second distnbutor object wishes -o 
receive: and 

where the filtering information indicates that the second distributor object wishes to receive the 
15 event report, forwarding the event report from the first distributor object to the second distributor object. 

15. In a data processing system having processing means and memory means, a method comprising ihe 
steps of: 

providing an event source object for generating an event report in response to an event and an 
30 event sink object for receiving the event report: and 

registering the event sink object to receive the event report from the event source object, wherem 
as part of the registration specifying an instance of a function in an interface to be called when the 
event report is received by the event sink object. 

25 16. The method of claim 15. further comprising the steps of: 
triggering the event at the event source object: 

generating the event report at the event source object and forwarding the event report to :he event 
sink object: and 

in response to receiving the event report at the event sink object, invoking the function of -he 
30 instance of the interface specified in the registration. 
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